dgit.raspbian.org Git - git-annex.git/blob

   1 [[!comment format=mdwn
   2  username="jkniiv"
   3  avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
   4  subject="comment 10"
   5  date="2023-07-12T16:25:48Z"
   6  content="""
   7 @nobodyinperson, @ewen: Thank you for a balanced discussion! I'm not as elegant with words
   8 but here is my take on your ideas.
   9
  10 @nobodyinperson:
  11
  12 > How about:
  13
  14 > - `git annex assist` (exists, works):
  15
  16 Yes, I understand the need for `assist` -- not in any way opposed to it. However, I think both
  17 `assist` and `sync` ought learn a new option called `--edit` (or, `--edit-message` but that's wordy)
  18 to be used in a similar fashion to `git commit -m msg --edit`, ie. it would open the user's preferred editor
  19 to edit the commit message.
  20
  21 > - `git annex metasync` (new proposal):
  22
  23 You mention that this command would be \"Option-wise as 'dumb' as git annex assist\" but I disagree: as a true
  24 replacement for `sync` it definitely should have at least the `--no-commit` flag as an additional option so that those
  25 used to a `git annex add; git commit -m foo [--edit]; git annex sync --no-content --no-commit` workflow could
  26 migrate to it. Also, no auto-adding (please!) if this is supposed be a replacement for `sync --no-content`.
  27
  28 > - `git annex sync` (exists, has many options and configs):
  29
  30 You mention that this command ought to be \"deprecated eventually (in many years), with a big warning upon execution now already\".
  31 Yes, I agree but only if we get a `metasync` with a `--no-commit` flag for reasons above.
  32
  33 ---
  34
  35 @ewen:
  36
  37 > Firstly, if `git annex assist` has been added to create the magical \"Dropbox like experience\", I don't see the need for changing the default behaviour of `git annex sync` at all.  (For the record I'm glad `git annex assist` exists; I don't need it, or want it, but it clearly solves a bunch of UI problems for some users, and that's great.  This is entirely about backwards incompatible UX changes in existing commands.)
  38
  39 I think you have a point there that the situation pre-10.20230626 would be preferable.
  40 But I can live with Yann's (@nobodyinperson) suggestions if there is some amount of compromising.
  41
  42 > Secondly, your (@nobodyinperson) suggestion for \"improving\" the current situation seems to be:
  43
  44 > 1.  Entirely remove `git annex sync` (entirely breaking backwards compatiblity) and/or have it permanently display a warning that cannot be removed (annoying, incompatible with anything looking at output); and
  45
  46 > 2.  Add a new (ie, not in any older version) `git annex metasync` which has some of the existing functionality, and some random other (unwanted by me at least) additional functionality (auto-adding any files in a directory where git annex is run, which I definitely do not want)
  47
  48 Yes, a replacement for `sync` should not in any case auto-add files. We want more control, not less.
  49
  50 (continued...)
  51 """]]